How Timers Are Managed

How Timers Are Managed

The IRIX kernel can be asked to implement itimers for many processes at once, each interval having a different length and starting at a different time. The kernel's method differs depending on the hardware architecture:

Some systems have no hardware support for interval timers, so the kernel has to rely on frequent, periodic interrupts as a time base.
In these systems, the precision of timer interrupts is controlled by a tuning paramater, the fasthz variable.
In the Challenge/Onyx and POWER-Challenge architecture, each CPU has a clock comparator that the kernel can program to cause an interrupt after a specific interval has elapsed.
In these systems, timer interrupts have sub-microsecond precision.

Timer Management in Challenge, Onyx, and POWER-Challenge

In the Challenge/Onyx and POWER-Challenge architectures, each CPU has a hardware-operated cycle counter and a hardware comparator that generates an interrupt when the comparator register matches the cycle counter. In these systems, the kernel can manage interval timers with the minimum number of interrupts.

The kernel keeps active itimerval structures in a list, sorted by ascending time until expiration.
The kernel calculates the cycle counter value at which the next interval timer will expire, and sets this value in the comparator register.
When the interval expires, an interrupt occurs.
The kernel processes the timer event: it sends the signal, and either removes the timer from the list or restarts it with a new interval, depending on itimerval.it_interval.

In the Challenge/Onyx systems, the number of timer interrupts the kernel must handle depends only on the number of active timer requests and their repetition rates. If there are many timers, or if there are repeating timers with very short intervals, there will be many interrupts. Normally there are fewer interrupts than in a system without a clock comparator.

Timer Management Without a Clock Comparator

In all uniprocessor systems and in the Crimson series (the only multiprocessor systems supported by IRIX 6.2 that lack a hardware clock comparator) the kernel manages interval timers using a periodic interrupt, as follows.

The kernel keeps active itimerval structures in a list.
The kernel arranges to be interrupted at a regular interval of length T.
On each timer interrupt, T is deducted from the it_value field of each active itimerval structure.
When the result is negative, the kernel processes the timer event: it sends the signal, and either removes the timer from the list or restarts it with a new interval.

The key point is the value of the periodic interval T at which the kernel updates timers. No timer interval can be shorter than T. The smaller the value of T, the more frequently the kernel must inspect all timers.

By default, T is one second divided by the value HZ defined in /usr/include/sys/param.h. In all recent versions of IRIX, HZ=100, so T, the minimum itimer interval, is 10 milliseconds. For normal processes--that is, processes not running at a nondegrading priority in the real-time band--no interval shorter than 10 milliseconds can be scheduled. The interval requested by a normal process is rounded up to whole multiples of 10 milliseconds.